One of the emerging communication technologies for delivering multimedia services across fixed and mobile access networks is the IP Multimedia Subsystem (IMS). The network architecture according to IMS comprises a service layer, control and connectivity layers, and an access layer. The control layer comprises call session control functions (CSCFs) forming central nodes for the provision of the SIP signaling (SIP: Session Initiation Protocol). The SIP protocol is one of the core technologies used by IMS for controlling the multimedia sessions combining voice and data streams.
A further core component of the IMS network architecture is the Service Capability Interaction Manager (SCIM) which was introduced in the 3GPP TS 23.002 standard as a function within a SIP Application Server domain of the IMS architecture. The role of the SCIM is that of a service broker in more complex service interaction scenarios which cannot be supported through the service filtering mechanism. The SCIM as proposed to the 3GPP uses an ISC interface to enable composite service behavior leveraging simpler service capabilities. In practical terms, a “capability” is a system component that may be used, presumably with other components, to implement a “service” that is packaged and delivered to end users of the network. For example, a group list server and a presence server may both be considered “capabilities” that are used to implement a sophisticated conferencing service. In this regard, an open issue in the 3GPP Release 9 specification is the orchestration of interaction between “capabilities” in the larger network which are represented as SIP Application Server instances. SCIM can be implemented using a service composition approach, where services, also called constituent services, may be aggregated to composite services. Composite services address complex user requirements that usually can not be covered by existing services. Hence, composite services offer added value in the form of new functionality compared to the sum of the functionality of their building blocks.
The service composition functionality usually introduces an entity—the service composition engine—that takes care of this complexity for the application. In this scenario the application implements just its core logic, whereas the enabling functionality, for example a “location-based weather forecast”, is exposed by the composition engine as a single service that may be easily discovered and bound by the application. In this case, the composition engine executes application logic in the form of the definition of the composite service, e.g. in this case the composite service “location-based weather forecast”. This composite service describes the type of required services, so that the engine—in particular at run-time—may discover, bind and execute appropriate services. Composition functionality, consequently, allows for great flexibility e.g. in handling events such as a faulty enabler. In this case, the engine could bind an alternative service without any disruption of the end-user application.
Composition sessions when executing composite services may contain session data. The session data are usually manipulated by the process according to instruction in its composite service description, i.e. as intended by a composite service designer. The data is either directly manipulated by these instructions, e.g. assigning a value to a variable, or indirectly, e.g. as results of services' invocations. Sometimes, this kind of composition session state data is also called “Shared State Data”, because they represent the state shared between all services participating in a given composition session.
If the composition session is performed on several nodes in a communication network, then an implementation of the composition engine performs a complete composition state replication to all nodes running the composition engine in the cluster or cloud. However, the performance of such an replication approach may not be optimal, as under load a lot of data has to be replicated which may lead to a performance degradation due to the usage of resources such as memory or network bandwidth overheads. Moreover, in geographically distributed configurations, where composition engines are running in different countries or even continents, e.g. at different subsidiaries of an operator, the exchange of huge data amounts over non-local networks may become a bottleneck reducing the performance of a composition engine.
Accordingly, there is a need for efficiently managing an execution of a composite service, in particular when session data is to be provided to service execution nodes, e.g. composition engines, arranged in a communication network.